IPTV is a technology used for delivery of broadcasted TV services over an IP network, typically a broadband access network. The predominant IPTV service today is Broadcast TV, wherein normal non-IPTV bearers, as well as additional bearers with low penetration, are transmitted from a super head-end to end user receivers, such as e.g. a Set Top Box (STB) connected to a TV screen, over a broadband network.
One way of delivering IPTV services to the end users is over an IP multimedia subsystem (IMS) based network architecture. FIG. 1 illustrates a simplified IMS based network architecture for delivery of multimedia services to end users, each of which is provided with a STB. In the figure a plurality of IMS enabled STBs 100a, 100b of an access domain 101 have access to multimedia services via an Application Server (AS) 102 of a Media and Service Discovery Platform 103. The services are controlled by Media Control Functions (MCF) 104, and delivered by Media Delivery Functions (MDF) 105 of a Media and Delivery Platform 106. An IMS core subsystem 107, comprising conventional Call Session Control Functions (CSCF), including Proxy-CSCFs (P-CSCF) 108, Interrogation-CSCSs (I-CSCF) 109, and Serving-CSCFs (S-CSCF) 110, controls the IPTV services, which may be delivered independently from different types of underlying IP based transport networks. It is to be understood that for simplicity reasons, nodes which may be compulsory for proper operation of delivery and control of IPTV services but which are not necessary for the understanding of the switching mechanisms which is the scope of this document have been omitted.
In order to minimize the bandwidth required for these transmissions and to minimize the resources required by the access network and in the aggregated transport network it is desirable to use multicast techniques. There are, however, a number of situations, such as for example when an end user is tuned in to a personalised TV service, and where it is necessary to switch to unicast stream while the end user is watching TV, distributed over a multicast connection. Examples of such cases are, e.g. during Network-Personal Video Recording (N-PVR) or when personalised advertising is applied. Live TV may be enabled by the Internet Group Management Protocol (IGMP), while Video on Demand (VoD) is another service which typically is enabled by the Real Time Streaming Protocol (RTSP). VoD allows a user to watch a program on a more individual basis. By using trick play functions or commands, such as e.g. pause, slow-motion and wind/re-wind, a user will have full control of a media stream transmitted via unicast.
According to known multicast techniques, an end user receiving a multicast service may have been configured to instruct the transmitting side to leave the present bearer and to join the new one, either by transmitting one Internet Group Management Protocol (IGMP) message, as proposed in the IGMP version 3 standards, or in two separate messages, as proposed in previous versions. Such a procedure may be applicable for both wire-line access and mobile access.
A method for performing a switching from multicast to unicast, according to the prior art TISPAN standards, will now be described in more detail, with reference to FIG. 2. In the figure a User Equipment (UE) 100, e.g. a STB, is receiving streamed media content, delivered from a Content or Service Provider (not shown), over an IP based network, typically an IMS based broadband access network, via a content server, which in this context is referred to as a MCF/MDF 105.
In an initial step 2:1, some trigger initiates a setup of a unicast bearer. According to the described method, this may be achieved by transmitting a re-invite message to a P-CSCF 108 in a next step 2:2, which is forwarded to an AS 102, such as e.g. a SCF, in a subsequent step 2:3. The re-invite message is a request for a RTSP setup, comprising a request for a certain bandwidth, which will be required for the requested unicast bearer. AS 102 responds to the re-invite message by setting up a necessary number of RTSP streams. A typical media transmission, will require one audio stream and one video stream, and, thus, for such a scenario, two RTSP setup procedures will be necessary, as illustrated with steps 2:4 and 2:6, respectively, wherein each setup steps are responded to by a 200 OK message in steps 2:5 and 2:7, respectively. UE 100 is notified of a successful setup via a 200 OK message, sent to P-CSCF 108 in a step 2:8, and forwarded to UE 100 in a subsequent step 2:9. From this moment, a unicast bearer is established between MCF/MDF 105 and UE 100, as a consequence, resources necessary for maintaining the bearer are also tied up.
If a resource reservation system is in place, an optional bandwidth reservation procedure may commence at this stage. For a fixed UE, such a procedure may typically be performed according to known TISPAN standards, as indicated with the optional steps 2:10a-2:10h. For a mobile UE, a corresponding bandwidth reservation procedure according to 3GPP standards may be executed instead. For a 3GPP implementation, RACS 200 will also be replaced by a Policy Charging Rule Function (PCRF).
In a step 2:10a an additional re-invite message, requesting for additional bandwidth, is transmitted to P-CSCF 108, which transmits a bandwidth resource reservation request to a Resource and Admission Control System (RACS) 200 in a subsequent a step 2:10b. If the required resources are available, RACS 200 responds by sending an OK message, according to the Diameter AAA protocol, to P-CSCF 108, as indicated with step 2:10c. The re-invite message is then forwarded to AS 102 in a subsequent step 2:10d, which is responded to with a 200 OK in a next step 2:10e. The reserved bandwidth is then committed in step 2:10f, and verified with another OK message, sent to P-CSCF 108 in another step 2:10g, and forwarded to UE 100 in a step 2:10h. 
The UE 100 is now ready to leave the multicast bearer, by transmitting an Internet Group Management Protocol (IGMP) leave to a Digital Subscriber Line Access Multiplexer (DSLAM) or the IP Edge router (not shown). This is indicated with another step 2:11.
As indicated with a subsequent step 2:12, UE 100 activates the unicast session by streaming control signalling, e.g. by transmitting an RTSP trick play command, such as e.g. RTSP PLAY, to MCF/MDF 105. The RTSP trick play command is responded to by MCF/MDF 105, with a 200 OK message, sent in a step 2:13. Optionally, the streaming control signalling may be executed in two steps, i.e. between UE 100 and AS 102, followed by forwarding the command from AS 102 to MCF/MDF 105. At this stage MCF/MDF 105 can start to transmit the media stream via unicast, as indicated in a final step 2:14.
However, switching from a multicast stream to a unicast stream typically results in a delay which is a disturbing obstacle for the service and/or network provider in its aim to offer a smooth and non-interrupted user experience. The experienced delay may have different causes, such as, e.g. the signalling between the UE and the stream control nodes, the bandwidth reservation made during the bandwidth renegotiation, the control signalling between the stream control nodes and the media servers, the setting-up of unicast streams for playout in the media servers, the delivery of the unicast stream, and/or the required buffering of the unicast stream.
Yet another problem with unicast solutions is that they are inherently resource limited, where typically the resource requirement grows linearly with the number of users tuned into unicast streaming, thereby causing problems to present scheduling mechanisms. It is therefore from a service deployment perspective advisable to limit the number of unicast connections to a minimum and to use these connections only on occasions when it is necessary.